Process management system

ABSTRACT

In a connection management system for setting up connections in a communications network, run-time negotiation is carried out to avoid feature interaction. Users of the network are provided with user agents (intelligent software) which have access to user profiles. When a calling user wants to set up a particular connection configuration, which may involve service features such as ring back later on busy, their user agent sends a connection configuration proposal to the user agent for a called user. The two user agents then negotiate to establish a mutually acceptable connection configuration, if one is available. The negotiation is based on alternative connection configurations stored in order of preference in the respective user profiles. These are proposed and counter-proposed by the user agents in descending preference order until the mutually acceptable configuration is reached or the connection fails.

BACKGROUND OF THE INVENTION

The present invention relates to process management systems. It findsparticular application in the provision of services over acommunications network, with particular reference to featureinteraction.

There are many processes which are complex and which can be carried outin more than one way. Embodiments of the present invention are intendedto select and configure the steps in a process.

An example of a complex process, which can be controlled by a managementsystem according to an embodiment of the present invention, is that ofservice provision over one or more communications networks. Recently,the services available to users over communications networks have grownmuch more sophisticated. For instance, in the UK, it is now possible tosubscribe to call waiting and answering services, provided over thepublic switched telecommunications network (PSTN). It is expected thatmodernisation of existing networks, and the provision of new networks,will lead to a proliferation of new services.

Increasingly in the future, different types of services are likely to beoffered over communications networks. For instance the increasingcapability of technology is enabling a future where a wide variety ofmultimedia services can be delivered to users over communicationsnetworks. These services could include simple voice telephony,multimedia conference amongst many users, home shopping and video ondemand. Additionally users may want such services to be delivered over avariety of terminal types such as a portable phone, portable personalcomputer and domestic television set with a set-top-box.

These services come not only from development of the telecommunicationsenvironment, including telephony and cable television, but also fromenvironments previously separate, such as the computing environment. Forinstance, there has been major growth of computer network services, suchas those available on the Internet. Collectively all these services arereferred to herein as information services.

Although to date (at least in the telephony world) the communicationnetwork operator and the service provider (SP) have generally coincided,this is not essential. Another trend expected in the future is that,increasingly, the service provider will be separate from the networkoperator. As in the case of Internet, several SPs (vendors) may offertheir services (products) over a common network. Indeed, there may befurther complexity involved in that the “common network” might in factcomprise multiple networks connected together, managed by many differentnetwork providers.

Communications services are based on functionality provided by thenetwork(s) carrying the services. In the telecommunications arena,recent developments mean that this could be provided increasingly byintelligence, ie decision-making software, in an intelligent networkarchitecture. With the convergence of computing and telecommunicationstechnology, however, functionality may in practice be provided in otherways.

Regardless of how functionality will be provided, there has emerged aproblem of “feature interaction”. This arises for instance when featureswhich would normally be triggered in provision of one service, conflictwith features normally triggered in provision of another service and thetwo services are called on at the same time. A simple example of featureinteraction is the conflict between “Call Forwarding” and “CallWaiting”. Clearly a call cannot be both forwarded and kept waiting.

As services grow more diverse, feature interaction has been found to bea very complex problem. It is considered one of the fundamentalobstacles to rapid development and deployment of new services. As thenumber of new features grows, the time required to introduce them grows.

In attempting to solve the feature interaction problem, a strategy hasbeen to classify the solutions into avoidance, detection and resolution.Avoidance looks at ways to prevent undesired feature interactions.Detection assumes that feature interactions will be present, anddetermines methods for identifying and locating them. Resolution assumesthat feature interactions will be present and detected, and looks atmechanisms for minimising their potential adverse effects. It is notpractical to assume that the solution can be provided by just oneapproach. Feature interactions found before deployment can be avoided.In contrast, feature interactions detected during run-time must beresolved at run-time. One advantage of run-time interaction resolutionis that the problem space is reduced, since only information specific toeach occurrence of an interaction need be considered.

Current approaches to run-time resolution include event based resolutionand negotiating software agents. Event based resolution is based on anapproach of collecting events during the basic call process whichtrigger the activation of features. In this way, the feature manager cancontrol which features should be invoked. These approaches can resolveissues such as signal ambiguities and incompatible combinations ofcall-processing activities. An alternative approach is to usenegotiating software agents proposed by Griffeths and Velthuijsen in“The Negotiating Agents Approach to Runtime Feature InteractionResolution”, published in 1994 by IOS Press. This approach uses agentsto represent users, network providers, and terminals, collectivelycalled entities. Users define policies which describe how each featureshould behave. These policies constrain the set of operations that eachuser or provider is willing to perform in initiating or modifying acall. A negotiation mechanism is used to resolve conflicts between thepolicies of different users, thus maintaining autonomy amongst theusers.

International patent application WO-A-94/27411 describes a method ofresolving conflicts among entities in a distributed system wherein anegotiating software agent represents each entity, the method beingbased upon generation of proposals and counter-proposals on the natureof a communication session to be established between those entities,selected by the agents from a goal hierarchy. A single goal hierarchy isused by all the agents involved in establishing the session althoughdifferent agents may mark a particular node within the hierarchyacceptable or unacceptable. On receiving an unacceptable proposal anagent may derive, from the goal hierarchy, the overriding goal of theuser initiating the proposal and hence select a counter-proposal fromwithin the same hierarchy.

In this description the term “agent” relates to a function or processwhich operates in a computing environment and which can act autonomouslyto receive a request for an operation and provide a result. An agentnormally has an up-datable data store for holding data relevant to localconditions, and usually also for holding some global information aboutthe disturbed environment in which it sits. Agents operate autonomously,having decision-making functionality (intelligence) allowing them tonegotiate and output a result in response to an incoming message. Theresult may be for instance a control signal to an apparatus. In thecommunications environment, the control signal may cause a connection tobe made according to a particular configuration.

Typically, an agent is embodied as a piece of software, for examplewritten in the C programming language, running on a suitable computingplatform, for example a UNIX (Trademark) based platform. Requests andresults are passed between an agent and a requesting entity, which mightbe another agent, across a suitable communications network, for examplea TCP/IP-based local area network, to which the computing platform isinterfaced. In some embodiments, plural agents can reside on a commoncomputing platform and, conversely, a single agent can be realisedacross plural computing platforms in the environment. Also, thecomputing environment might be heterogeneous, and support variousdifferent types of computing platforms.

SUMMARY OF THE INVENTION

According to a first aspect of the present invention, there is provideda method of processing data in data processing means, so as to generatean output signal in response to at least one input signal, wherein theinput signal comprises at least one data element, which methodcomprises:

i) storing a set of data elements;

ii) allocating to each stored data element a weighting factor;

iii) receiving said input signal;

iv) for each data element of the input signal, searching for that dataelement in the stored set of data elements;

v) for each data element of the input signal which is found by thesearch in the stored set of data elements, reviewing the weightingfactor allocated to that data element; and

vi) generating an output signal determined by the reviewed weightingfactors.

Preferably, there are provided at least first and second data processingmeans, wherein the input signal is received by the first data processingmeans from the second data processing means and the output signal issent by the first data processing means to the second data processingmeans, said output signal comprising a response selected from:

a) acceptance;

b) rejection; and

c) a signal comprising at least one data element.

In embodiments of the present invention, the data processing means for afirst entity and a second entity can make proposals and counterproposals to each other over the way in which a process is to be carriedout. Each data processing means looks at its own preferences, the“weighting factors”, for the elements of the proposal incoming from theother data processing means. If it can put forward a counter proposalwhich is more acceptable to it in the light of its own preferences, itwill do so and wait for the other data processing means to review thecounter proposal in its turn, against its own preferences.

Clearly, there will be circumstances where a data processing meansaccepts a proposal even though it can put forward a better proposal fromits point of view. For instance, this will happen if it has already hadthe “better” proposal rejected, or if the negotiation process has becometoo protracted.

Processes other than communications service configuration which mightbenefit from an embodiment of the present invention would include forinstance establishing parameters such as costs and timing for electronictrading and transfer of funds, establishing access and download of data,and information filtering.

Embodiments of the present invention are particularly useful whendirected to identifying and resolving feature interactions incommunications service provision at runtime.

According to a second aspect of the present invention, there is provideda method of establishing a connection over a communications network, forservice provision between first and second users of the network, therebeing provided respective connection setup means for said users, whichmethod comprises:

i) storing for each of said users data defining at least one connectionconfiguration;

ii) storing in respect of data defining a connection configuration forthe second user, data defining at least one alternative connectionconfiguration; and

iii) storing in respect of said data defining a connection configurationfor the second user, and in respect of the data defining the or each ofits alternative connection configuration(s), a respective priorityindicator;

the method further comprising a negotiation process for theestablishment of a connection by means of:

iv) transmitting data defining a proposed connection configuration fromthe connection setup means for the first user to the connection set upmeans for the second user;

v) reviewing the data defining the proposed configuration at theconnection setup means for the second user by accessing the datadefining configurations and the respective priority indicators stored inrespect of the second user; and

vi) selecting and transmitting a response to the connection setup meansfor the first user, the response being determined at least in part bythe result of the review step v) above, and selected from acceptance orrejection of the proposed connection configuration, or comprising datadefining a counter-proposed connection configuration.

According to a third aspect of the present invention, there is providedapparatus for use in establishing communications connections by means ofa communications network, the apparatus comprising:

i) first and second network access points;

ii) at least one data store for storing user profiles, each user profilecomprising a set of connection configurations associated with arespective user, and for storing priority indicators in relation to atleast two of said connection configurations; and

iii) first and second connection set up means for use in establishingconnections between said access points,

wherein said first and second connection set up means are each providedwith a negotiation protocol, access to at least one user profile in thedata store, and means to review said priority indicators for that userprofile, such that a communication connection can be set up between theaccess points, on behalf of at least two users, by negotiation betweenthe first and second connection set up means, based on the respectiveuser profiles and the related priority indicators.

It will be seen that embodiments of the present invention allow featureinteractions to be circumvented at run-time for a communications serviceby means of a user being able to preselect to abandon a service aspectin response to a potential compromise proposal from another user bybuilding in an order of preference for service aspects.

Significant aspects of preferred embodiments of the present inventionfor use in communications service provision are:

the introduction of scheduling so that an otherwise failed connectioncan be reattempted

the provision of a preference order for connection configurations

a negotiation strategy which can be varied both in general terms andspecifically for each user

the facility to send multiple connection configurations between users,and the negotiation protocol offered

the representation of features as high level goals,

how these high level goals are mapped into a user configuration, and

the way in which agents, acting on behalf of the users involved in anygiven connection, negotiate in the connection setup process.

Although embodiments of the invention are clearly very useful incommunications service provision, as described above, they can also haveapplication in a wide range of process environments. Wherever there is achoice in the way elements of a process might be carried out, andwherever there are different entities involved in the carrying out ofthe process, which entities may have different preferences, then anembodiment of the present invention may be appropriate.

TERMINOLOGY

For the purposes of this patent specification, we will define thefollowing terms:

Feature

A feature is a tariffable unit, e.g. Call Waiting. There can be twotypes of feature. A technology feature is an individual operation thatthe platform performs. A policy feature on the other hand, is aconstraint on the set of operations that a user or provider is willingto perform in initiating or modifying a call. Embodiments of the presentinvention relate to this second type of feature.

Service

A service is a collection of features. A feature modifies one or moreaspects of a service, while using the remaining functionality provided.An example of a service is that currently offered by the presentapplicant in the UK: “Network Services”. This comprises the features“Call Waiting”, “Call Diversion”, “3 Way Calling” and others.

Feature Interaction

A feature interaction occurs when the behaviour of one feature affectsthe behaviour of another feature.

It should be noted that although the word “call” is used throughout thisspecification, embodiments of the present invention should not be takento be limited to voice or speech transmission. The principles of theinvention will clearly also be relevant to other transmissions, forinstance potentially involving data or information transmission.

It is recognised that computing infrastructures in telecommunicationscan become extremely complex and this could potentially limitmanageability, extendibility, scalability and robustness. The approachexploited in embodiments of the present invention, which providessimplicity in the infrastructure, is that of intelligent agenttechnology, the basis of which is described in “Distributed ArtificialIntelligence”, ed. Huhns M. N., Pitman, London 1987. An intelligentagent in this context can be broadly described as a software basedentity which acts on behalf of another entity. It might compriseupdatable data, which might only be locally relevant, and usually somesort of negotiating or decision-making functionality. A community ofagents can then perform negotiation tasks amongst themselves to decide away forward on behalf of multiple entities in a distributed system.

Software clearly provides the basis of the infrastructures needed inservice provision systems according to embodiments of the presentinvention to implement scalable and deployable solutions. Differenttypes of software technology might be employed, and there are severalfunctional design approaches which could be used. However, a commonapproach to the design and implementation of software systems in thistechnical environment uses object oriented software technology. This isknown and used by international standards bodies (e.g. Open SoftwareFoundation Object Management Group (OSF OMG), Open SystemsInterconnection (OSI)). Reference might be made for example to “ObjectManagement Architecture Guide”, Revision 2.0, Second Edition, Sep. 1,1992. OMG reference: OMG TC Document 92.11.1.

In general terms, “objects” in this context comprise units of softwarewhich represent entities or concepts of the real world by means of acombination of data and functionality. Data is encapsulated as internalattributes of an object and the associated functionality is encapsulatedas methods which use or operate upon the attributes. Although an objectmay receive a message from another object requesting it to perform amethod on its attributes which may result in the return of data, theattributes themselves are not directly accessible by external objects.Such high degrees of encapsulation have not been readily available inearlier software technologies.

Embodiments of the present invention are advantageously based onobject-oriented technology.

From the perspective of the enterprises involved in satisfying theoverall requirements of users in the future, there are likely to besignificant challenges involved in designing a suitable infrastructure.A potential starting point would clearly be provision of an architecture(from high-level design to low-level implementation) that cantechnically and economically support services of the future. Softwareand hardware resources of the computing infra-structure would beenabling components of the service architecture. An aspect of thecomputing infrastructure is the processing environment and a knownenvironment of suitable type for use in embodiments of the presentinvention is the distributed processing environment (DPE) which allowsmultiple processes to be run using multiple computer “nodes”. The DPEmaintains a view of the multiple nodes and processes and handles messagepassing between nodes and objects, providing a common language for theexporting of interfaces for different objects residing on differentnodes. That is, it assists with aspects of the software and hardwarelocation transparency and facilitates the provision of scalable anddeployable solutions. Standards for DPE already exist and are beingextended.

A node in this context might conveniently be provided by a computer withprocessors and memory which is capable of running an operating system,compatible distributed processing platform and objects executed asprocesses on the computer.

Another advantageous characteristic would be that the communicationnetwork (or networks) itself is capable of transmitting a wide range ofservices. There are network technologies which are capable of supportingmultiple service delivery and some examples of these are based on theasynchronous transfer mode (ATM) and synchronous digital hierarchy (SDH)technologies. A common feature of such networks is that they can use arange of transmission rates flexibly, choosing that most appropriate forthe service being delivered.

Future service retailing might be offered across an architecture of thetelecommunication information networking architecture type. This bringstogether elements of the multi-service network and DPE technologiesmentioned. An example of such an architecture is that being defined bythe TINA Consortium. Reference might be made to “TelecommunicationsInformation Networking Architecture”, Oshisanwo A., Boyd T., Proc. 4thIEEE Conf. Telecommunications, IEEE, London 1993.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the present invention will now be described, by way ofexample only, with reference to the accompanying Figures in which:

FIG. 1 shows information, computational and engineering representationsof a system architecture for use in designing embodiments of the presentinvention;

FIG. 2 shows the structure of a DPE relevant to FIG. 1;

FIG. 3 shows a principally hardware view of platform for use inembodiments of the present invention;

FIG. 4 shows an overall multiple agent architecture and communicationlinks between agents and supporting elements;

FIG. 5 shows an internal architecture for a user agent for use in thearchitecture of FIG. 4;

FIG. 6 shows a data set relevant to a user agent as shown in FIG. 5;

FIGS. 7 and 8 show protocols for user agents of a caller and a calleeduring call set-up;

FIG. 9 shows a high level system model for embodiments of the presentinvention;

FIG. 10 shows an object model for the application described as anembodiment of the present invention;

FIGS. 11 and 12 show process steps involved in logging on and attemptingto make a call using an embodiment of the present invention; and

FIG. 13 shows a goal hierarchy for use in solutions according to theprior art.

DETAILED DESCRIPTION OF THE INVENTION

As mentioned above, a suitable technical context for embodiments of thepresent invention would be an information networking architecture of thetype defined by the Telecommunications Information NetworkingArchitecture Consortium (TINA-C). Such an architecture is based on OpenDistributed Processing (ODP) principles of object orientation anddistribution, applied to telecommunications system design usingTelecommunications Management Network (TMN) managed objects andIntelligent Network (IN) concepts for service management and control.

In a TINA-C architecture, there are three sets of concepts, a logicalframework architecture, a service architecture, and a managementarchitecture.

The logical framework architecture defines concepts and principles forthe design of object-oriented software that operates in a distributedenvironment. Here a traditional layered computer architecture isdefined, with computers and computer networks at the bottom, adistributed processing environment (DPE) in the middle, and(object-oriented) application software on top.

The application software is itself subject to organisation in TINA-C.The service architecture defines basic object types, and rules for theirusage that can be used to design application software that providesservices. A service is defined as a meaningful set of capabilitiesprovided to a user. A service may have many users in different roles.For example, the end-user is the person who uses the service for itsintended function, the service manager manages the service, and thenetwork provider provides and manages the underlying resources requiredby a service. The notion of service in TINA-C applies to allapplications that are accessible to users, including managementservices. The service architecture contains a call model suitable for awide range of service types.

The management architecture defines object types, and rules for theirusage, that can be used to design application software to manageservices, networks and computing systems.

The (known) OMG type DPE core provides for communications betweenobjects, provides dynamic bindings via a trader function and providesnotification servers to give management information (such as faults,performance and the like). It provides generic “Application ProgrammingInterfaces” (APIs) and message passing facilities. All applicationsoftware is assumed to run on a DPE.

Available documentation, in addition to the reference given above,includes a set of deliverables, such as “O-O Modelling and Design”, by JRumbaugh et al, published by Prentice Hall in 1991, “OverallArchitecture” TINA-C Deliverable 1994 by M Chapman et al and “Guidelinesfor the Definition of Managed Objects”, published in “The Management ofTelecommunications Networks” edited by R Smith et al and published byEllis-Horwood in 1992.

System Design Techniques

Referring to FIG. 1, to enable system design according to a TINA-Carchitecture, three ODP viewpoints can be selected, these being asfollows:

Information: a viewpoint on a system that focuses on the semantics ofinformation and information processing activities in the system.

Computational: a viewpoint on a system that focuses on the distributablesoftware objects and their interactions.

Engineering: a viewpoint on a system that focuses on the deployment anddistribution aspects of the system and on the infrastructure to supportdistribution.

For each of these, a set of modelling concepts are defined, providing avocabulary that can be used to specify a system in the viewpointaddressed.

The information modelling concepts shown in FIG. 1a provide theframework for information specifications, describing the types 801, 802of information used in a system and the activities that are performed onthe information. An information specification describes the semantics ofthe problem domain that the application software is being designed for.For example, in a banking scenario an information model may containobjects such as account, debit, credit, and balance, and relationshipssuch as debits plus credits equals balance.

The fundamental concepts of information modelling are objects, which areinformation bearing entities, object types 801, 802, that classifyobjects and define an object's characteristics in terms of attributesand operations that may be performed on objects, and relationships 803that define links between, and aggregations of, objects.

Within TINA-C the notation chosen for information specifications is theISO/IEC and ITU-T recommended GDMO (Guidelines for the Definition ofManaged Objects) with GRM (General Relationship Model). GDMO isextensively used in the TMN community for information modelling and thusallows TINA-C to directly reuse this work. Rumbaugh's OMT (ObjectManagement Tool) notation (described in “Object-Oriented Modelling andDesign”, by Rumbaugh et al, published by Prentice-Hall in 1991) is usedfor graphical representation of information specifications.

The computational modelling concepts shown in FIG. 1b provide theframework for computational specifications. A computationalspecification describes distributed telecommunications applications interms of computational objects 805 interacting with each other.Computational objects are defined without any knowledge of where thecomputational objects will eventually be deployed i.e. distribution ismade transparent. This allows for the specification of a software systemthat can tolerate the redeployment of software onto different nodes of anetwork without affecting the specification. The fundamental concepts ofcomputational modelling are objects 805 and interfaces 806, 807. Objectsare the units of programming, and encapsulation. Objects interact witheach other by the sending and receiving of information to and frominterfaces. An object may provide many interfaces, either of the same ordifferent types. There are two forms of interface that an object mayoffer or use: operational interface 806 and stream interface 807. Anoperational interface 806 is one that has defined operations, that allowfor functions of an offering (server) object 809 to be invoked by other(client) objects. An operation may have arguments and may returnresults. A stream interface 807 is one without operations (i.e. there isno notion of input/output parameters, requests, results, ornotifications). The establishment of a stream between stream interfaces807 allows for the passing of other structured information, such asvideo or voice bit streams.

A notation which might be chosen for computational specifications isTINA-C ODL (Object Definition Language), which is an enhancement of OMGIDL (Object Management Group Interface Definition Language). TINA-C hasextended OMG IDL to allow for the definition of objects that havemultiple interfaces and for the definition of stream interfaces.

The engineering modelling concepts shown in FIG. 1c provide theframework for engineering specifications. An engineering specificationdescribes the deployment view of a system in terms of whichcomputational objects 805, 809 are placed on what computing node 810. Italso defines the infrastructure to allow objects to execute andcommunicate with each other.

DPE and Hardware Context

Referring to FIG. 2, the infrastructure aspects of the engineering modelwill define the Distributed Processing Environment (DPE). As mentionedabove the DPE is an infrastructure (of known type) that supports theinteractions of computational objects. The DPE shields applicationsprograms from the heterogeneous and distributed nature of the underlyingenvironment, and provides the mechanism that allows objects to interactwithout knowing the computing nodes 810 they are on. The DPE definesfour types of entity: DPE kernel 811, kernel transport network 901, DPEstubs, and DPE servers 809.

The DPE kernel defines a core set of communications, storage andprocessing capabilities (e.g., protocol stack). This core set is assumedto be present on each node.

The kernel transport network 901 is a communications network to whichall DPE kernels are attached in order to exchange messages to facilitateobject interaction. It is defined in order to logically separate thecomputing network from a transport network which is used for thetransmission of voice and video. The logical separation recognises thatthe two networks may have different requirements on quality of service.However, they may both be implemented by the same physical network.

DPE stubs are software modules linked with computational objects whichintercept interactions on objects, and use the underlying kerneltransport network 901 to establish bindings and to transmit and receiveinvocation messages to and from remote objects. In practice, aninterface for an object is designed and compiled. This generates a stubwhich will receive incoming messages to the object and select whichoperation is to be invoked by means of the interface.

DPE servers 809 provide infrastructure support. Two examples might be atrader and a notification server. A trader provides a run-time mechanismthat allows objects to locate the interfaces of other objects. Anotification server enables objects to emit notifications (i.e.significant events that occur during the lifetime of an object) to otherobjects. Objects wishing to receive notifications register at run-timewith the notification server.

Referring to FIG. 3, the hardware view of a system in which embodimentsof the present invention might be built is based on a transport network1100 which will carry for instance voice and data services, provided byservice providers to users. The users will be connected to the networkby different pieces of customer premises equipment (CPE) 1101, 1102. Thevarious parties involved in offering and carrying those services, suchas the service retailer, service provider and network provider, are alsoconnected at computational nodes 810 to the transport network 1100.Intelligent software agents, for instance a terminal agent 102 and auser agent 107, will sit on either the same or different ones ofcomputational nodes 810 connected to the transport network 1100.

As shown in FIG. 3, the terminal agent 102 and user agent 107 sit on thesame computational node 810. These agents are provided with data ofvarious types, including for instance user profiles in a user profilestore 1103 which happens to share the computational node 810 with theuser agent 107 and terminal agent 102. Other data stores available bymeans of the transport network 1100, as shown, might for instanceinclude a management information data store 1105. The managementinformation data store 1105 may provide global management information inrespect of services. Each computational node 810 is provided with a DPEkernel 811, and therefore a protocol stack for use according to DPEprinciples.

“Session” and “Access” Concepts

TINA-C systems make use of “session” concepts and “access concepts.These are as follows.

Session concepts define those objects and interfaces that are requiredto support the initiation of, interaction with, and termination ofservices. Although services by their nature are different from eachother, they all have a common fundamental property in that they providea context for relating activities. Such a context is termed a Session.As a generic definition, the term session represents a temporal periodduring which activities are carried out with the purpose of achieving agoal. Three types of session have been identified: service session, usersession, and communications session.

A Service session is the single activation of a service. It relates theusers of the service together so that they can interact with each otherand share entities, such as documents or blackboards. A service sessionlogically contains the service logic. A service session iscomputationally represented by a service session manager. A servicesession manager offers two types of operational interfaces. The first isa generic session control interface. This provides operations that allowusers to join and leave a service. For certain services it may alsooffer operations to suspend and resume involvement in a service. Thesecond type of interface will provide service specific operations, andwill be dictated by the capabilities offered by the service logic.

The ability to suspend and resume involvement in a service is adesirable feature for some services. For example, consider a multi-mediaconference that occurs over several days. During the night, when theconference is not in use, it should be possible to release expensivecommunications resources. The service session can maintain state aboutthe conference, such as the users and resources involved. Maintenance ofstate and the ability to suspend and resume involvement would avoid theneed for tearing down and recreating the service each day.

A User session maintains state about a user's activities and theresources allocated for their involvement in a service session. Examplesof state held in a user session include the user's accumulated charge,suspension and resumption history, and service specific state such asthe current page being edited in a distributed document editing service,for example. When a user joins a service session, a user session iscreated. It is deleted when he leaves. The service session maintainslinks to the user sessions and thus provides a group oriented view.

A Communication session is a service oriented abstraction of connectionsin the transport network. A communication session maintains state aboutthe connections of a particular service session, such as thecommunication paths, end-points and quality of service characteristic. Acommunication session is required only when stream between computationalobjects are required. Computationally a communication session managerprovides the features of a communication session. It provides aconnection graph interface of a service session to manipulate. Aconnection graph is an abstraction that defines concepts such asend-points and lines. A service session expresses connectivityrequirements be adding, removing and linking end-points and lines. Aservice session manager will request connectivity between streaminterfaces of computational objects. The communication session managercalls upon connection management objects to establish physicalconnections between the network access points of the relevant computingnode, and nodal services that allow for a network access point to beconnected to the software stream interface. Connection managementcomponents are not discussed further in this specification.

A user can be simultaneously involved in multiple service sessions. Aservice session has one or more users associated with it, and for eachassociated user there will be a related user session. A service sessionmay have one or more communication sessions if the service involvesstream communication. A communication session is related to exactly oneservice session.

The purpose of these separations is to decouple service orientedactivities from connection oriented activities. Many types of servicesmay exist in a future network and not all will require the explicitestablishment of connections (streams). The service session is thereforea point of control for all service types, creating communicationsessions when necessary.

Access concepts define those objects and interfaces that support userand terminal access to services.

Users need to have flexible access to services, in terms of thelocations from which they access the service and the types of terminalthey use. User access is therefore distinguished from terminal access.An agent concept is used in defining the TINA-C access model. An agentis this context is a computational object, or collection of objects,that acts on behalf of another entity.

A user agent 107 represents and acts on behalf of a user. It receivesrequests from users to establish service sessions, or to join existingservice sessions, and creates or negotiates with existing servicesessions as appropriate. The creation of a service session by a useragent 107 can be subject to subscription and authentication checks. Auser agent 107 also receives and processes requests to join a servicesession from service sessions themselves. This is a form of in-comingcall processing where another user has created a service session andinvites the user to join in. User agents 107 know the subscribedservices that a user may create. This list can be presented to the userwhen the user logs on to his user agent 107.

A terminal agent 102 is responsible for representing a terminal. It isresponsible for obtaining the precise location of a terminal. Twoexamples are; the network access point a portable computer is attachedto, and the cell in which a mobile phone is currently located.

In order to access a service, users must associate their user agents 107with terminal agents 102. This is part of a logging on process. A usermay be simultaneously associated with many terminals. For example, in avideo conference a user may be using both a workstation and a telephone.Similarly a terminal may be simultaneously associated with many users,for example, when in a meeting all users associated their user agentswith the telephone in the meeting room.

User and terminal agents 107, 102 are computational objects that shouldhave high reliability properties. These are required so that the networksoftware can rely on a fixed point for locating users and terminals inan environment where both may be moving around.

1. Agent Architecture

This section describes the architecture of agents involved inembodiments of the present invention. It is important to note that theapplication described in the following example(s) only buildsintelligence into the user agents, i.e. the negotiation process onlyoccurs between the user agents. Thus, while Terminal Agents and NetworkAgents exist, there is no intelligence in these agents for the purposeof the present description.

1.1 Inter-Agent Architecture

Referring to FIG. 4, agents 405 are located on a number of hosts 810.Each host 810 has a UNIX process running, called an “office” 400.Communication between hosts 810 is carried out through the “office”process 400. The communication is based on TCP/IP sockets, using a port(e.g. port 7000). Communication between agents 405 and an office 400located on the same host 810 are performed through “pipes”. Informationfrom the Terminal Agents is also communicated to User Interfaces 410through the same communication mechanism.

1.2 Intra-Agent Architecture

Referring to FIG. 5, the intelligence of the User Agent 107 is comprisedof five principal objects: Customer 500, TermSession 505, Session 510,Negotiator 515 and Evaluator 520. Two other objects, io and parser525,530, are required for communication from other objects and agents,and ensuring messages are passed on to the appropriate object. Thefollowing sections give an overview of the functionality of each object.

Customer Object 500

The customer object handles:

(i) logging on and off

(ii) initial queries concerning the configuration information

(iii) initial request to accept a call from a caller

TermSession Object 505

A terminal session object is created by the caller whenever a request ismade to logon at a terminal. The TermSession object 505 handles theinitial request by the Caller to make a call

Session Object 510

A Session object 510 is created whenever a new call is made. Thefollowing functionality is provided:

(i) Receiving messages concerning the termination of calls either by thecallee or from the network

(ii) Sending requests for user validation to the User Agent Manager

Negotiator Object 515

A negotiator object 515 is created upon creation of a session object 510and succesful validation of a User Agent 107 by the User Agent Manager.The negotiator object 515 handles which message operations to sendbetween the caller and callee's User Agent 107 when a call attempt ismade.

Evaluator Object 520

The Evaluator object 520 calculates the initial proposal and subsequentresponses to a proposal when a call attempt is made.

2. Knowledge Representation

Referring to FIGS. 3 and 6, the user agent 107 contains all the currentintelligence. It accesses stored information in the User Profile andUser Policies datastore 1103. The User Profile contains information on auser's id, password and their preferences while the User Policiesdatastore holds information on the strategies which should be deployed.

The preferences may include information concerning when calls can be setup at later times (i.e. dynamic time-of-day routing).

When a user logs on, they access the user agent 107 via the User AgentManager (“CustMan Object” in the Terminal Agent). The user agent 107accesses the user profile 600 for that user and displays it on screen.

If a user logs off from a terminal, the mode will be changed eitherautomatically or by the user. Otherwise, a user may simply change modesto indicate they have temporarily left a machine without logging off.

2.1 Feature Representation

Referring to FIG. 13, in known agent-based systems such as thatdescribed by Griffeths & Velthuijsen (referenced above), a goalhierarchy 1300 can be used to represent the possible plans which canachieve the goals of all the agents involved.

In FIG. 13, one subscriber who has an unlisted number proposes a call toanother subscriber with calling number delivery (CND). As the subscriberwith an unlisted number does not want his or her number to be generallyknown, this unlisted number (UN) feature is incompatible with thecalling number delivery feature. On receipt of this proposal, CND seesthat the proposal does not include the delivery of the number and thusreturns the previous proposal with calling-number-delivery added. UNreceives this proposal and decides that it is unacceptable. However, heis able to offer a counter-proposal, using his goal hierarchy, with thename delivery instead of the number delivery. This is acceptable to CNDand thus returns notification of this agreement.

While, this represents a useful approach in terms of considering theuser's behaviours, there are a number of limitations:

(i) the representation is not rich enough to model more complexconstraints such as time;

(ii) there are no preferences expressed as to which of the possibilitiesa user would prefer;

(iii) a single goal hierarchy is required for all users. Some users maynot wish other users to know their user policies; and

(iv) the model could not represent combinations of achieving a call viaother mediums of transmission.

In embodiments of the present invention, at least one or more of theselimitations can be overcome. A feature can be represented in terms of ahigh level goal. Taking the goal of not wanting to be disturbed unlessurgent, this can be expressed in the form of an ordered set of lowerlevel, alternative goals:

i) wanting all calls to go to a mailbox

ii) to be delegated to some named person.

iii) or, if urgent, will take the call

High level goals can thus be mapped into sets of alternative callconfigurations which can be ranked according to preference. This mappingcan be hard coded or achieved through a set of rules which willdynamically assign preference ratings based on a series of questionswhich guide the user as to which goals they wish to achieve.

As an example, Call Waiting is a service which can be represented as themore general goal of a user not wanting to miss urgent calls.

These high level goals can be used to describe both incoming andoutgoing calls. Some further examples are given in the table below:

High Level Goal Outgoing Calls I don't want callees to know my phonenumber I want outgoing calls to complete now rather than later I want toreach the person concerned if possible rather than voicemail I want toreserve a time to call back if possible if the callee's line is busy(this might be an urgent call or because I am only available now) I wantcallee to reserve a time to call me back if possible if their line isbusy Incoming Calls I do not want to be disturbed unless it is urgent Ido not want to take calls between times x and y I want to know who'scalling me before I answer I want all incoming calls to complete

2.2 User Configuration

A user's configuration describes how a user prefers their calls(incoming and outgoing) to be handled. The user's configuration defines,for both incoming and outgoing calls, a set of call configurationoptions. Each call configuration option within the set is represented bya set of attributes, together with their associated values, and a basicpreference rating. Some of the attributes will be fixed, while otherswill specify a range of values. In the latter case, a numericalindicator will be specified with one or more of the alternative valueswhich indicates an amount to be decremented from the basic preferencerating. Thus, each call configuration option of the set has a range ofassociated preference ratings. This is further discussed below.

By defining a preference structure in relation to a set of callconfigurations, the user can give priority to one choice of callconfiguration over another and thus determine a negotiation pattern forthat user's agent.

It might be noted that the user agent 107 is persistent. Decisions cantherefore be made whether or not the user is active. Also, preferenceswill usually be set, or changed, prior to call set-up, rather thanduring.

The following describes firstly the attributes for use in callconfigurations, and then how a preference structure is applied to thoseattributes, for a particular user.

2.2.1 Call Configuration Attributes

The attributes describing a particular call configuration arecommunicated between agents during a negotiation process in the form ofproposals and counter-proposals. A call configuration is defined by thefollowing attributes:

(i) caller values: {person, recorded}

This attribute defines who is calling. The caller may be an actualperson or it may be a recorded message in the case when the callee isnot available to receive calls or mail messages at the present time. Thecaller may leave a recorded message which then gets sent to the calleeat a predetermined time or when the callee next logs on.

(ii) callee: values: {person, queue, mailbox}

This attribute defines how the callee wishes to handle a call. There arethree possible values: either (i) the call will be taken by a persondirectly, (ii) the call can be put in a queue, or (iii) the call can besent to the mailbox.

(iii) callee-who values: {direct, someone-else [X,Y,,,]}

This attribute defines whether the callee will be the person requestedor whether the call will be taken by someone else. In this latter case,a parameter specifies a list of delegates.

(iv) authorised values: {yes, no}

This attribute defines whether the call needs an authorisation code.

(v) medium values: {voice, video, text}

This attribute defines which medium is being used to transmit the call.The ‘video’ value includes voice.

(vi) schedule values: {now, caller [time], callee [time]}

This attribute defines whether the call is to be taken now or whether itwill be taken later. In the latter case, it defines the responsibilityfor setting up the call (caller/callee) and a time parameter whichspecifies one of the following possibilities: ‘before t1’, ‘after t1’,‘at t1’, ‘asap’.

(vii) caller info values: {none, name, number}

This attribute represents what information the caller is prepared toprovide to the callee. It may take a subset of the above values.

(viii) callee info values: {none, name, number}

This attribute represents what information the callee is prepared toaccept from the caller. It may take a subset of the above values.

2.2.2 Call Configuration Options Ordered by Preference Ranges

It is possible to identify a “mode” of operation for a user. This is inpractice a high level goal which predetermines some lower level goalsand defines a context of operation such as calls to be directed to amailbox, or person to person only. In practice, the mode can beselected, or determined, by selecting values from the first two or threeattributes in a call configuration: caller, callee and callee-who. (Thethird attribute is only required if the second attribute uses the value‘person’.)

“Do Not Disturb” Mode

In an example, shown in FIG. 6, a user's top priority might be for allincoming calls to be diverted to the mailbox. If this cannot beachieved, calls should be delegated to a named person, and failing thatthe call might be taken if it really is urgent. This high level goal,with the three options, could be expressed in the form of a ‘do notdisturb’ mode 600. Each option for the “do not disturb” mode is given abasic preference rating, selected to reflect the order of preference.Hence the basic preference rating for “Mailbox” option 605 might be 100,for the “delegated” option 610 the basic preference rating might be 90,and for the “call taken” option the basic preference rating might be 79.

Looking at the “Mailbox” option 605, the top priority can be expressedby selecting the following values for the first three attributes andassigning the maximum basic preference rating to this choice: 100.

Preference Value: 100 Caller person Callee mailbox Callee-who direct(default value)

Having defined these attributes, values can then be defined for theother attributes. For each of these attribute values, there may also beuser preferences. For example, the user may prefer calls to beauthorised and/or the medium to be voice rather than video. Thesepreferences can be expressed by decrementing the basic preference ratingfor the “Mailbox” option by a relevant amount for each of thealternatives it is preferred should not be accepted. That is, each suchalternative value is given a negative preference rating. A minimumpreference rating for a set of call configurations providing one of thethree options (ie the bottom end of the preference range for thatoption) can therefore be determined by summing all the possible negativepreference ratings which can occur within a single call configurationand subtracting this from the basic preference rating for the option.

One possible set of values are shown below for the ‘mailbox’ option 605:

Preference Range 100-92 Caller person: yes (0), recorded: no Calleeperson: no; queue: no; mailbox: yes (0) Callee-Who direct: yes (0)Authorisation present: no | absent: yes (0) Medium voice: yes (−3) |video: yes (−5) | text: yes (0) Schedule now: yes (0) | caller callsback: no | callee calls back: no Caller Info Forename: present: yes (0);absent: no Surname: present: yes (0); absent: no Company: present: no;absent: yes (0) Callee info Forename: present: yes (0); absent: noSurname: present: yes (−3); absent: yes (0), Company: present: no;absent: yes (0)

The table above defines a set of proposed call configurations for the“Mailbox” option 605 (ie where the callee is “mailbox”). The basicpreference rating has been set at 100 because the user prefers thisoption most. There are three values with negative preference ratings,these being where the medium is “voice” or “video” and the calleesurname is present. The worst combination available available is mediumbeing “video” (−5) and callee surname present (−3). This provides a sumof −8. Hence the preference range for this “Mailbox” option 605 is100-92.

An example of one proposed call configuration within this option may bedefined as:

caller: person

callee: mailbox

calleeWho: direct

authorised: absent

schedule: now

medium: text

caller forename: present

callee forename: present, surname: present which produces a preferencerating for this particular user of 97, based on the basic preferencerating (100) minus the preference rating for the callee surname present(−3).

This process is repeated by defining the set of call configurations,together with preference ratings, for the two other options for the mode“Do Not Disturb”: delegated calls 610 and receiving a call 615. The ‘donot disturb’ mode is then defined by the union of these three sets.

As shown in FIG. 6, another available mode might be “No Calls” 620. Thisonly differs at first sight, as shown, in the last option which replaces“Now-Take Call” with “Later” 625. However, the preference ratings forthe first and second options in this mode, “Now-Mailbox” 630 and“Now-Delegate” 635, may actually be very different in this mode fromwhat they are for the same options in the “Do Not Disturb” mode 600.Indeed, as shown, the preference ranges are now 100-87 and 85-70 asshown.

An analogous outgoing mode, ‘completing a call’, may represent the goalsin decreasing preference of attempting to call a person directly,accepting a delegated call, or failing that leaving a message.

The total set of call configurations for incoming and outgoing callsdefine a user's “negotiation space”, which provides the framework toenable the user agents to make decisions about which goals they wish toachieve.

2.2.3 Example

In the following example, the caller, Mr Smithers wishes to call MrsRichers. Mr Smithers prefers to call Mrs Richers directly rather thanleave a message in her mailbox. He also prefers to setup the call nowrather than set up the call later.

Mrs Richers on the other hand, is in the ‘do not disturb’ mode. She doesnot want to be interrupted now.

This information can be represented by the two sets of callconfigurations shown below. A negative number alongside an attributevalue indicates that should that option be taken, the preference ratingwill be decreased by that amount.

Where no multiple values are specified, this implies that only thatvalue will be acceptable in that particular set.

2.2.3.1 Caller's Ordered Set of Call Configuration Options (i.e. MrSmithers'):

Mode: Contact person now either person-to-person or leave mail message.

Call Configuration Option a): Preference Range: 100-91

Caller: person

Callee: person

who: direct

authorisation: no/yes (−1)

medium: voice

schedule: now/caller sets up call later (−8)

caller info: none

Call Configuration Option b): Preference Range: 90-80

Caller: person

Callee: mailbox

who: direct

authorisation: no/yes (−1)

medium: voice/text (−9)

schedule: now

caller info: none

2.2.3.2 Callee's Ordered Set of Call Configuration Options (i.e. MrsRichers'):

Mode: Do not disturb

Call Configuration Option a): Preference Range: 100-90

Caller: person/recorded (−1)

Callee: mailbox

Who: direct

Authorisation: no

Medium: voice/video/text (−3)

Schedule: now

Callee info: name/[ ] (−6)

Call Configuration Option b): Preference Range: 90-80

Caller: person/recorded (−1)

Callee: person

Who: someone-else [Fred] (−5),/someone-else [George] (−7),

Authorisation: no

Medium: voice/video

Schedule: now

Callee info: name/none (−2)

Call Configuration Option c): Preference Range: 80-70

Caller: person

Callee: person

Who: direct

Authorisation: yes/no (−6)

Medium: voice/video

Schedule: caller set up call later

Callee info: name/none (−4)

2.2.4 User Profile

A user's profile describes the mapping from the set of high level goalsdefined by the user to the call configurations. An example is given byFIG. 6.

3. Negotiation

On making a call, a user triggers their user agent. The user agentrefers to the user's profile, generates a proposal and transmits it tothe callee's user agent. The proposal will comprise one or more callconfigurations.

On receipt of a proposal, a negotiation process is initiated. Thecallee's agent is required to accept the proposal, counter with aproposal of their own or reject the proposal. To do that, the callee'suser agent will first review the proposal against their own modes,options and preferences to see if there is at least one acceptable callconfiguration in the proposal. If there isn't, the callee's user agentneeds to generate a counter proposal, unless the incoming proposal wastoo far below the callee's agent's stored preferences. If the latter istrue, then the callee's user agent may reject the incoming proposal andthe connection will simply fail. If it isn't true, the callee's agentmay send back a counter-proposal and the negotiation will continue.

Each agent involved determines their response to a proposal or counterproposal in the negotiation process by taking into account their set ofpreferences within a given context. The aim is to select and put inplace a call configuration which describes a mutually acceptable callhandling scenario. That is, a call configuration which falls in thenegotiation space of both agents.

Referring to FIGS. 7 and 8, the negotiation process is now described inmore detail.

A proposal, or counter-proposal defines a particular call configuration.In order to communicate these proposals and counter-proposals betweenuser's agents, a number of performatives are introduced. Theseperformatives are given below together with an informal description:

Performative Description accept-if This offer describes a set ofproposals which are acceptable. It does not however exclude otherpossibilities which are not specified in this offer. fail-if-not Thisoffer describes a set of proposals which if the other user does notaccept, forces a failure and the end of the negotiation process.acceptance the caller/callee user's agent have agreed to a proposal orcounter proposal resolution the callee has agreed to the proposal putforward by the caller failure the caller/callee's User Agent or thecaller/callee cannot agree to any proposals and so the negotiation endssucceed the caller and callee's User Agent have already agreed to a setof proposals and now the caller/callee chooses which particular proposalfrom the set of proposals offered. It is possible that a caller willsend a set of proposals which is a singleton. In this case, the calleecan subsequently receive a resolution.

3.1 Protocol

Referring to FIGS. 7 and 8, the protocol is defined using a statetransition diagram to show the sequence of permitted messages for boththe caller and callee. For the purpose of these diagrams, an exclamationmark (!) indicates ‘send’ to other user and a question mark(?) indicates‘receive’ from other user.

A further constraint is also placed on the protocol such that if aconfiguration has been proposed using an ‘accept-if’ performative, andit has been refused by the other parties involved in the negotiation, itis not possible to repeat this configuration.

Negotiation is based on:

the knowledge representation used to express the goals and preferencesbetween goals

the strategy used to determine the type of proposal to send and how toevaluate a proposal received from another user's agent.

The knowledge representation has been discussed above. It is the use ofgoals, expressed as call configuration attributes, together with theassociated preference ratings. Interagent communication is then carriedout, using knowledge representations, according to a protocol of thefollowing type.

FIGS. 7 and 8 show state transition diagrams for a caller and a calleerespectively. They describe what message operations are possible giventhe state (initial/proposed/confirmed/succeed) 705, 710, 715, 725 andwhich party (caller/callee) has sent the message. A number of possibleevents (proposal, counter, succeed (proposals), acceptance, resolutionand failure) 720 can occur at each given state.

The object structure describes the content of the negotiation, which inthe context of this application, is the proposal describing thecombination of call characteristics to be performed.

3.2 Decision Process

This section describes:

how an individual agent makes a decision as to which message operationto send, and

how an agent decides upon the content of the proposal or counterproposal if one is offered.

3.2.1 Environmental Parameters

When a request is made by a caller to make a call, some staticinformation is used:

caller (Name)—the name of the caller

delegated (Via)—if calls have been delegated to someone else, the ‘Via’field is filled in with the name of the callee who decided to delegatetheir calls.

callclass(Class)—the class defines whether the call is business orpersonal.

In addition, proposals must also take account of a number of attributeswhich define the environment:

(i) mode—determines the context in which the user wishes to make orreceive calls, e.g. ‘do not disturb’, ‘contact callee directly’, etc.

(ii) state of a session—free, busy

(iii) location—determined by the Terminal Agent which can identify theuser's host machine which the user is logged into

(iv) intentions—commitments a user has made together with theirassociated priority

(v) current negotiations—other negotiations the user is involved in, butwhich have not yet come to a successful conclusion

These attributes determine the set of proposals from which the initialproposal will be chosen.

3.2.2. Generating Initial Proposal

As mentioned in the previous section, the environmental parametersconstrain the set of possible proposals from which any proposal can beselected. The initial proposal will be generated by selecting theproposal from this set with the highest preference rating.

3.2.3 Generating Counter Offers

The process given below provides an overview of how a user agent shouldrespond to an offer:

1. Find a possible proposal using the next highest preference fromprofile. This preference will take into account the current state of theuser, i.e. free or busy, together with previous proposals which havefailed. If a preference can be found, go to step 2, else, send a messageback to the other user agent indicating a failure together with thereason.

2. Check the possible proposal against intentions. If this passes, go tostep 3, else go back to step 1 with a message indicating a failuretogether with the reason.

3. Check the possible proposal against current negotiations. If thispasses, then send proposal back to other user agent indicating thecounter proposal together with the reason why counter proposal is beingsent. If this fails, then go back to step 1 with a message indicating afailure together with the reason.

Two types of counter offers can be made:

‘Accept if’

This offer describes a set of proposals which are acceptable and havenot previously been sent. It does not however exclude otherpossibilities which are not specified in this offer.

‘Fail if not’

This offer describes a set of proposals which if the other does notaccept, forces the end of the negotiation process. This offer reducesthe negotiation space.

3.2.4 Strategies

General

A number of strategies can be generated using the form of the counterproposals discussed above. One such strategy is shown below:

1. If

receive Accept If (proposed) and

f(proposal, myPreferences)=accept then

send ‘accept(proposal)’

The function “f(proposal, myPreferences)” determines whether theproposal is acceptable or not by examining the list of proposals.

if

the size of the list of possible proposals>size_(proplist)

then

if

the pref(proposal)>pref_(accept) (your threshold value)

then

accept (proposal)

else

counter with your best proposal from current negotiation space

else

accept(proposal)

2. If

receive a proposal which is unacceptable (i.e. there is no intersectionbetween what has been proposed and the set of acceptable proposals basedon your preferences), then

send ‘Fail If Not(whole set of proposals)’

else

send ‘Accept If (top x % of your preferences)

The first step in the strategy will tend to make call configurationslower down the preference order more acceptable as the negotiationprocess continues.

The parameters size_(proplist), pref_(accept), x can all be variedgiving different degrees of co-operativeness.

A mathematical expression defining a strategy is as follows. Thestrategy defines the reasoning used to evaluate the following:

initial proposal to offer

counter-proposal from the other user's agent

response to be made to the other user's counter-proposal

Let the negotiation space for user_(i) at time t_(x) be defined byNS_(i, tx), where NS_(i, tx) is an ordered set of call configurations{c₁, c₂, . . . ,c_(n)} such that U(c_(i))<U(c(_(i+1)), where U(c_(i))represents the preference of c_(i). Let C_(i,,tx) and C_(j,tx) representthe set of proposals and counter-proposals being offered by user_(i) anduser_(j), at time t_(x), respectively. We define a number of parameters,which affect a user's degree of cooperation

(i) Let G be such that C_(i,tx)={c_(min), . . . , c_(max)}, such thatc_(x)≦c_(x+1), x=min, . . . ,max−1, where U[c_(min)]=G %*U[c_(max)]. Wecan think of G as representing the generosity of the user and dictatesthe lowest preference value to offer in a set of proposals

(ii) Let D be such that if a set of call configurations, C_(j, tx−1),are offered in a counter-proposal, it will be accepted at time t_(x) iflength (NS_(i, tx))≦D, and NS_(i, tx−1) ∩ C_(j, tx−1)≠Ø. The value Drepresents a user's desperateness to agree to a proposal.

(iii) Let A be a constant, such that the set of call configurations,C_(i, tx), will be offered at time t_(x) such that:

U[min(C _(j, tx−1))]≧A %*U[c _(max)] and C _(i, tx) ⊂C _(j, tx−1),

where C_(j, tx−1) was the counter-proposal offered by agent j at timet_(x−1). This parameter defines the level of acceptability of a proposalfrom the other user.

The strategy for user_(i) at stage t_(x), x≧0, can then be formulated asa set of rules defining the proposal, p_(i,tx), offered at time, t_(x).We have three main cases:

(i) p_(i,t0)=<accept if, C_(i, t0)> where U[c_(min)]=G %*U[c_(max)],C_(i, t0)={c_(min), . . . , c_(max)}, len(NS_(i, t0))≧D, andNS_(i, t1)=NS_(i, t1)\C_(i, t0)

(ii) If p_(j,tx−1)=<accept-if, C_(j, tx−1)>, ∀x, x>0, then we have thefollowing sub-cases:

a) p_(j,tx)=<accept-if, C_(j, tx)>, U[c_(min)]=G %*U[c_(max)],NS_(i, tx)=NS_(i, tx−1)\C_(j, tx−1), if NS_(i, tx−1)∩C_(j, tx−1)≠Ø andlen(NS_(i, tx))≧D, x≧1

b) p_(j,tx)=<fail-if-not, C_(j, tx)> andC_(j, tx)=NS_(i, tx)=NS_(i, tx−1) if ∃x≧1, p_(i,tx−1)≠<fail-if-not,C_(i, tx−1)> and

NS_(i, tx−1)∩C_(j, tx)=Ø,

a) p_(j,tx)=<succeed, C_(i, tx)>, U[c_(min)]=G %*U[c_(max)], if(C_(i, tx) ⊂C_(j, tx−1), U[min(C_(j, tx−1))]≧A %*U[c_(max)], or length(NS_(i, tx))≦D) and NS_(i, tx−1)∩C_(j, tx−1)≠Ø

iii) If p_(i,tx−1)=<fail-if-not, C_(j, tx−1)> then we have twosub-cases:

a) If C_(j,tx−1)∩NS_(i, tx−1)=Ø, then p_(j,tx)=<failure>

b) If C_(j,tx−1)∩NS_(i, tx−1)Ø and len(NS_(i, tx))≧D, x≧1, whereNS_(i, tx)=INS_(i, tx−1)∩C_(j, tx−1)), then

p_(j,tx)=<accept-if, C_(j, tx)>, U[c_(min)]=G %*U[c_(max)],C_(i, tx)⊂C_(j, tx−1),

The parameters G, D and A can be varied to provide a greater or lesserdegree of cooperation.

There are two important aspects of the strategy set out above, thesebeing the “Accept If” and “Fail If Not” mechanisms. Between them, theyreduce the negotiation space for the user agents in a relatively shortnumber of rounds of negotiation, for instance four or five rounds. The“Accept If” proposal reduces the negotiation space of the sending agentsince those configurations cannot be resent. The “Fail If Not” proposallimits the negotiation space for both agents to what is contained inthat proposal.

The way a negotiation might proceed is that a first agent selects aproposal from its top six preferred call configurations. A second agentlooks at its own negotiation space and finds the proposal doesn't evenmeet its lowest criteria, ie the bottom of its preference range. Thesecond agent therefore sends its whole negotiation space as a “Fail IfNot” proposal. The first agent selects from the “Fail If Not” proposaland sends an “Accept If” proposal. For instance, the first agent mayhave found on review that only six call configurations from the “Fail IfNot” proposal fall in its preference range. The second agent sends backthe best one of the call configurations and the negotiation succeeds andis resolved.

This type of negotiation strategy clearly has application to negotiationprocedures other than simply those used in communications, in callsetup, and is independently inventive in the context of software agentsnegotiating to select a mutually acceptable solution from a negotiationspace which comprises a range of options which can each be broken upinto sub-options and weighted preferentially. For instance, this wouldbe the case where agents are negotiating to establish a pricing strategyover a commodity with multiple components where the components can bemixed and matched to get an optimum combination. This applies in thetravel industry where a product (overseas travel) has many differentcomponents such as travel mode, accommodation and timing.

4. Connection Setup in the TINA-C Environment

The following describes the setting up of a service session in a TINA-Cenvironment, including the use of user agents to implement an embodimentof the present invention to select and put in place a mutuallyacceptable configuration for the service session.

The application uses the TINA-C framework as a basis for determiningindividual agent roles and the sequence of interactions between each ofthe agents in order to establish a service session.

(It should be noted that, by adopting the TINA ‘session’ concept, it ispossible to avoid the need to represent some features. An example ofthis is a feature called ‘Call Waiting’, which enables users to switchbetween two calls. This feature does not exist as such in the TINAsystem, since a user can receive any number of calls simultaneously.Every time an incoming call is accepted, a new ‘call’ window appears onthe terminal screen, which is associated with a unique sessionidentifier.)

Referring to FIG. 9, a system model gives a high level view of thesystem.

The User Agent 107 contains the intelligence to negotiate on behalf ofUsers to set up a call.

The Terminal Agent 102 holds information on the resources available andlocation of a station.

The Network Agent 110 controls the logical and physical connectionsbetween the locations of the users involved in calls.

The Application 950 represents the particular program chosen to performa call. This may be for instance a simple voice call or a multi-mediaconference call.

The User Interface 410 allows the user to make and receive calls, accessand change their user configurations.

4.1 Object Model

FIG. 10 shows object models for the principal objects of a user agent107 and a terminal agent 102. Descriptions of the objects are givenbelow.

4.2 Object Description

(It should be noted that messages of known type which simply instruct anobject or agent to perform a task are not set out below. Only “speechact messages” are detailed. These have a semantic nature, e.g. to informor request.)

4.2.1 User Agent

4.2.1.1 Customer Object 1005

Attributes

name—customer's name

passwd—password

Creation method

A customer object is created using the call:

Create(Cust)

where the following parameters are used:

(i) Cust—Customer

Speech Act Messages

The customer object respond to the following speech act messages:

(I) act=inform, nature=logon, address=Address, password=Password,agent=Agent

This message emanates from the User Interface via the Terminal Agentinforming the customer object that the user is logging on.

(ii) act=inform, nature=logoff, address=Address, agent=Agent

This message emanates from the User Interface via the Terminal Agentinforming the customer object that the user is logging off.

(iii) act=inform, nature=logoff, address=Address, obj=cust,customer=Customer, password=Password

This message emanates from the User Interface via the Terminal Agentinforming about the password

(iv) act=request, nature=config, address=Address, agent=Agent

This message emanates from the User Interface via the Terminal Agent,requesting the User Agent's configuration information

(v) act=inform, nature=config, config=Config, address=Address,agent=Agent

This message emanates from the User Interface via the Terminal Agentinforming the User Agent of a change in the Configuration information.

(vi) act=proposal, proposal=Proposal, session=SessionId, agent=Agent

This message emanates from the Caller's User Agent via the negotiatorobject requesting the Callee's User Agent to accept an initial proposal

4.2.1.2 TermSession Object 1000

Attributes

The attributes for the TermSession object 1000 are:

terminal—Terminal Agent

location—name of the station

Creation method

A TermSession object 1000 is created using the call:

create(Agent, Address)

where the following parameters are used:

(i) Agent—Customer

(ii) Address—location of the Terminal Agent

Speech Act Messages

The TermSession object 1000 responds to the following speech actmessages:

(i) act=request, nature=makecall, callee=Callee, proposal=Password,address=Address, agent=Agent

This message emanates from the User Interface via the Terminal Agent torequest to make a call.

4.2.1.3 Session Object 1010

Attributes

The attributes for the Session object 1010 are:

initial proposal—the initial proposal put forward by the caller

other agent—the other agent involved in the call setup

session id—a unique identifier (Caller User Agent, Id)

Creation method

A Session object 1010 is created using the following call:

Create(Agent, Proposal, Session id)

On creating a session, the following parameters are used:

(i) Agent—the other User Agent involved in the call,

(ii) Proposal—the initial proposal

(iii) SessionId—session identifier

Speech Act Messages

The Session methods respond to the following speech act messages:

(i) act=inform, nature=userquery, response=ok, user=Agent

A query response from the User Agent Manager to inform the User Agentthat the User Agent (Agent) exists.

(ii) act=inform, nature=userquery, response=notok, user=Agent

A query response from the User Agent Manager to inform the User Agentthat the User Agent does not exist.

(iii) act=inform, nature=connectfail, session=SessionId

A message from the network to inform the User Agent that the connectionhas failed.

(iv) act=inform, nature=connectend, session=SessionId

A message from the network to inform the User Agent that the connectionhas been terminated.

4.2.1.4 Negotiator Object 1020

Attributes

The attributes for the Negotiator object 1020 are:

state—the current state (initial, proposed, confirm)

direct—who is controlling the negotiation (send implies control, receiveimplies someone else has proposed)

proposals—a list of proposals seen so far, with the latest proposal atthe beginning of the list.

otherneg—the other user agent involved in the session

session—the joint negotiation Id generated by the controller

Creation method

The Negotiator object 1020 is created using the call:

create(Agent, ProposalParameter, SessionId, Direct)

where the following attributes are used:

(i) Agent—the other User Agent involved in the call

(ii) ProposalParameter—the proposal made as part of the call

(iii) SessionId—the SessionId created by the caller's User Agent

(iv) Direct—who is controlling the negotiation (send implies control,receive implies someone else has proposed)

Speech Act Messages

The Negotiator object 1020 responds to the following speech actmessages:

(I) act=acceptance, session=SessionId, agent=OtherAgent

This message emanates from the other agent's negotiator objectrequesting acceptance for a call setup.

(ii) act=counter, session=SessionId, proposal=OtherProposal,agent=OtherAgent

This message emanates from the other agent's negotiator object informingthe agent of a counter proposal.

(iii) act=failure, session=SessionId, agent=OtherAgent

This message emanates from the other agent's negotiator object informingthe agent that the negotiation has terminated unsuccessfully

(iv) act=resolution, session=SessionId, agent=OtherAgent

This message emanates from the other agent's negotiator object informingthe agent that the negotiation has terminated with a successfulconclusion.

4.2.1.5 Evaluator Object 1015

Attributes

There are no attributes for the Evaluator object 1015.

Creation method

The Evaluator object 1015 does not have to be created.

Speech Act Messages

There are no speech acts applicable to this object.

4.2.2 Terminal Agent

4.2.2.1 io_listen Object 1025

Attributes

The attributes of this object are:

socket—server socket

port—socket

loctemplate—address name

Creation method

The io_listen object is created using the call:

create(port)

where port refers to a socket

Speech Act Messages

There are no speech act messages.

4.2.2.2 io_port Object 1030

Attributes

The attributes of the io_port object are:

socket—socket

location—location name

customer—customer name

program—application (rtgui)

agent—terminal agent name

Creation method

The io_port object is created using the following call:

create(socket, Template)

where the attributes are:

(i) socket—socket

(ii) Template—Template name containing the host and port number

Speech Act Messages

The io_port object responds to the following messages:

(i) act=inform, program=Program, host=Host

A message from the User Interface to inform the Terminal Agent about theapplication and host.

(ii) act=inform, nature=logon, customer=Cust

A message from the User Interface to inform the Terminal Agent aboutlogging on.

(iii) act=inform, nature=logoff, customer=Cust

A message from the User Interface to inform the Terminal Agent aboutlogging off.

(iv) act=request, nature=config, customer=Cust

A message from the User Interface to request the Terminal Agent for theconfiguration information.

(v) act=inform, nature=config, config=Con, customer=Cust

A message from the User Interface to inform the Terminal Agent aboutchanges to the configuration information.

(vi) act=inform, nature=makeCall, callee=Callee, mymode=Mode,preferences=preferences

A message from the User Interface to inform the Terminal Agent about amake call.

(vii) act=inform, nature=logresponse, address=Cust:Program@Location,password=Password

A message from the User Agent via the Customer object to inform theTerminal Agent about a response to a logon.

(viii) act=inform, nature=nosuchcust, address=Cust:Program@Location

A message from the User Agent via the Customer object to inform theTerminal Agent about a response to a logon and the User Agent does notexist.

(ix) act=reply, config=Config, address=Cust:Program@Location

A message from the User Agent via the Customer object to inform theTerminal Agent about its configuration information

4.2.2.3 User Agent Manager (Cust Man) Object 1035

Attributes

The attributes for the custman object are:

functor—function of the agent (i.e. user agent)

Creation method

There are no parameters called to the create method:

Speech Act Messages

The custman object responds to the following speech act messages:

(I) act=inform, nature=logon, address=Address, password=Password,agent=Agent

This message emanates from the Terminal Agent requesting a logon.

(ii) act=request, nature=userquery, user=User, agent=Agent

This message emanates from the User Agent requesting a query of theexistence of the agent (User).

5. Scenarios

Referring to FIGS. 11 and 12, the following process steps apply duringlog on by a user and a call attempt by a user. It will be seen that thenumbers given below to the process steps are repeated in FIGS. 11 and 12to indicate which entities are involved in each process step.

5.1 User Logging On

Process

The User opens the runtime application.

1,2. A ‘login window’ is displayed once the User Interface hasregistered a connection with the Terminal Agent

3. The User enters his/her userId and password. A message is sent to theTerminal Agent to request logging on, together with the userId andpassword to the Terminal Agent.

4. On receipt of this request, the Terminal Agent passes on the requestto the User Agent Manager.

5. The User Agent Manager sends this message on to the relevant UserAgent via its customer object.

6. The Customer object creates a Termsession object, identified by theTerminal Agent which sent the message and the name of the station beingused.

7. The Caller's User Agent via the customer object determines thevalidity of the user. If the password is correct, a message is sent tothe Terminal Agent.

8. On receipt of a ‘logresponse’ message, the Terminal Agent sends amessage back to the originating User Interface located on the identifiedstation.

At this point, the main application window is displayed, enabling usersto make or receive calls.

5.2 User Attempting To Make A Call

Process

1. On selecting the ‘make call’ button from the User Interface, amessage is sent to the Terminal Agent, containing the proposal,calleeID, mode, preferences and customer.

2. On receipt of the message, the caller's Terminal Agent sends amessage containing the calleeID, current location, situation andproposal to the caller's User Agent via the TerminalSession object. (Thepreferences are not used at this point. This only defines who is beingcalled and the mode which has been selected—it is not until Step 7 thatthe preferences based on the mode and other factors such as currentstate, are used to generate a proposal).

3. On receipt of this message, the Terminal Session object creates a newSession object.

4. If the SessionId is empty, then a new Session identifier is createdusing the ordered pair, (Caller's User Agent, Id). The Caller's UserAgent will then send a message to the User Agent Manager to query thevalidity of the Callee.

If the SessionId already exists, then the user is responding to arequest to join in an existing session.(see Step ) and the SessionIdwill be taken from the existing session.

5. On receipt of this message, the User Agent Manager validates theCallee and sends a message back to the Caller's User Agent via theSession object with the appropriate response.

6. On receipt of a successful response, the Session object creates anegotiator object, identified by the SessionId.

7. On creation of the negotiator object, the negotiator requests theevaluator to generate an initial proposal.

8. The negotiator object sends the proposal together with the SessionIdto the Callee's User Agent via the customer object.

9. On receipt of this message, the Callee's User Agent via the Customerobject creates a Session object using the existing SessionId.

10. The Session object creates a Negotiator object for the Callee's UserAgent using the existing SessionId.

11. The negotiator object asks the evaluator object to calculate aresponse to the initial proposal.

12. A message is sent back to the Caller's User Agent via the Negotiatorobject with the appropriate response.

13. On receipt of this message, the Negotiator object requests theevaluator to calculate a response. This is continued until the Caller'sUser Agent decides to accept or reject the proposal.

If the response is to accept the proposal, the Callee's User Agent willsend a message to the User Interface via the Terminal Agent to promptthe Callee to accept the call. If the Callee decides to accept the call,a message is sent back to the Terminal Agent to accept the call and thisresults in a ‘resolution’ message being sent back to the Caller's UserAgent.

If the response is to reject the proposal, both the Caller and Callee'sUser Agent will inform their respective users that the call cannot bemade and the negotiation will end.

The following steps have made some assumptions concerning what decisionsare made.

14. The Caller's User Agent via the negotiator object sends a messageback to the Callee's User Agent via its negotiator.

15. The Callee's User Agent via its negotiator calls the evaluatorobject to calculate a response.

16. The evaluator decides to accept the counter offer. The negotiatorobject sends a message to the Terminal Agent to prompt the Callee toaccept the call.

17, 18. The Callee via the User Interface receives the message and sendsa message back to the Terminal Agent to accept the call.

19. The Terminal Agent receives the confirmation from the Callee andsends a message back to the Callee's User Agent via its negotiator.

20. The negotiator sends a message back to the Caller's User Agent viaits negotiator object informing the User Agent that the call proposalhas been agreed.

At this point the negotiator object asks the Session object to send amessage to the network to proceed with the connection and to prompt theCaller that the call setup has been agreed.

It might be noted that although the “callee” will usually be a person,it could also be inanimate. For instance, if a user is not currentlylogged on, the callee will be a mailbox.

What is claimed is:
 1. A method of establishing a connection over acommunications network, for service provision between first and secondusers of the network, there being provided respective connection set-upmeans for said users, which method comprises: i) storing for each ofsaid users data defining at least one connection configuration, saidconnection configuration comprising at least one operation of thecommunications network in combination with an operation to beimplemented at least in part by functionality of the connection set-upmeans; ii) storing in respect of data defining a connectionconfiguration for the second user, data defining at least onealternative connection configuration; and iii) storing in respect ofsaid data defining a connection configuration for the second user, andin respect of the data defining the or each of its alternativeconnection configuration(s), a respective priority indicator; the methodfurther comprising a negotiation process for the establishment of aconnection by means of: iv) transmitting data defining a proposedconnection configuration from the connection set-up means for the firstuser to the connection set up means for the second user, said proposedconnection configuration comprising at least one of an operation of thecommunications network and an operation to be implemented at least inpart by functionality of the connection set-up means for the first user;v) reviewing the data defining the proposed configuration at theconnection set-up means for the second user by accessing the datadefining configurations and the respective priority indicators stored inrespect of the second user; and vi) selecting and transmitting aresponse to the connection set-up means for the first user, the responsebeing determined at least in part by the result of the review step v)above, and selected from acceptance or rejection of the proposedconnection configuration, or comprising data defining a counter-proposedconnection configuration, without having access to the stored datadefining at least one connection configuration in respect of the firstuser.
 2. A method according to claim 1 wherein the data defining anoperation to be performed at least in part by the connection setup meanscomprises time data and, in the event that the response is acceptance ofa connection configuration comprising time data, the connection setupmeans subsequently attempts to set up a connection in accordance withsaid time data.
 3. A method according to claim 2 wherein said time datacomprises a time of day and the connection setup means subsequentlyattempts to establish connection at that time of day.
 4. A methodaccording to claim 2 wherein said time data comprises a time intervaland the connection set up means subsequently attempts to establishconnection after said time interval has passed.
 5. A method according toclaim 1 wherein, in the event that the response comprises data defininga counter-proposed connection configuration, the negotiation processfurther comprises: vii) reviewing the data defining a counter-proposedconnection configuration at the connection setup means for the firstuser by accessing the data defining configurations and respectivepriority indicators stored in respect of the first user; and viii)selecting and transmitting a response to the connection setup means forthe second user, the response being determined at least in part by theresult of the review step vii) above, and selected from acceptance orrejection of the counter-proposed connection configuration, orcomprising data defining a further counter-proposed connectionconfiguration.
 6. A method according to claim 5 wherein steps v) throughviii) are carried out, and repeated if necessary, until a transmittedresponse is acceptance or rejection of a proposal.
 7. A method accordingto claim 6 which further comprises the step of logging, by theconnection setup means for each user and at least for the duration of asingle negotiation process, received connection configuration proposals,any subsequent proposal transmitted by either connection set up meansexcluding proposals previously transmitted by either connection setupmeans.
 8. A method according to claim 1 which further comprises the stepof storing, for each of said users, any current data relevant toconnection setup for that user, in addition to data defining connectionconfigurations, and the negotiation process further comprises the stepof reviewing the additional data prior to transmission of data defininga proposed or counter-proposed connection configuration, and modifyingthe data defining a proposed or counter-proposed connectionconfiguration accordingly.
 9. A method according to claim 8 wherein theadditional data comprises one or more of the following: a) connectionmode data; b) location data for the relevant user with respect to thenetwork; c) commitment data, indicating commitments previously made bythe relevant user; and d) concurrent negotiation process data for therelevant user.
 10. A method according to claim 6 wherein the datadefining each proposed or counter-proposed connection configurationtransmitted from a connection setup means is selected for transmissionin accordance with a progression from proposals with a high priorityindicator towards proposals with a relatively lower priority indicator,for the relevant user.
 11. A method according to claim 1 wherein eachconnection setup means can be provided for a plurality of users andwherein the method can be carried out concurrently by a connection setupmeans for more than one user.
 12. A method according to claim 1, whereineach connection configuration comprises one or more features providing acomponent of a communications service, the features being selected froma set of features at least two of which are mutually incompatible. 13.An apparatus for use in establishing a communications connection betweena first access point and at least one further access point of acommunications network, the apparatus comprising connection set-up meansassociated with said first access point, the apparatus furthercomprising: an interface to the communications network for activatingnetwork operations available at said first access point; a data storefor storing data defining at least one connection configuration and anassociated priority indicator in respect of said first access point,said connection configuration comprising at least one operation of thecommunications network in combination with an operation to beimplemented at least in part by functionality of said connection set-upmeans; wherein said connection set-up means comprise: means to implementa negotiation process, in co-operation with connection set-up meansassociated with said at least one further access point, to agree a setof operations of the communications network and of said connectionset-up means for implementing said communications connection; and meansto implement said agreed set of operations in respect of said firstaccess point; said negotiation process comprising the steps of: (i)receiving data defining a proposed connection configuration; (ii)reviewing the received data in comparison with connection configurationdata and priority indicators stored in the data store; and (iii)selecting and transmitting a response to said received proposal, theresponse being determined at least in part by the result of the reviewstep (ii) and selected from acceptance or rejection of the proposedconnection configuration or comprising data defining a counter-proposedconnection configuration.
 14. Apparatus according to claim 13 whereinthe data defining an operation to be performed at least in part by therespective connection setup means comprises a time data field andwherein at least one connection setup means is provided with schedulingmeans for scheduling connection setup initiation in accordance with thecontent of a time data field.
 15. A method of operating a controlapparatus, wherein the control apparatus is arranged to trigger anagreed set of operations comprising at least one of a plurality ofoperations external to the apparatus and an operation comprisingfunctionality of the control apparatus in combination with at least oneof said plurality of operations external to the apparatus, the methodcomprising the steps: i) storing a set of data elements, at least one ofsaid data elements comprising data defining an attribute of an operationof the control apparatus in combination with data defining an operationexternal to the control apparatus; ii) allocating to each data element aweighting factor; iii) receiving an input signal representative of aproposed set of operations, expressed in terms of at least one dataelement; iv) for each data element in the input signal, searching forthat data element in the stored set of data elements; v) for each dataelement of the input signal which is found by the search in the storedset of data elements, reviewing the weighting factor allocated to thatdata element; and vi) generating an output signal, determined by thereviewed weighting factors and representative of a response to theproposal, the response being selected from agreement or rejection of theproposal or comprising at least one data element representing acounter-proposed set of operations.
 16. A method according to claim 15wherein the review of one or more weighting factors comprises summingthe total of the weighting factors and comparing the summed total with astored value.
 17. A method of processing data according to claim 15,involving first and second data processing means, wherein the inputsignal is received by the first data processing means from the seconddata processing means and the output signal is sent by the first dataprocessing means to the second data processing means.
 18. A methodaccording to claim 17 wherein, in the case that the output signalcomprises one or more combinations of data elements, together with acondition indicator, the first data processing means stores a record ofsaid combinations and bars subsequent output signals by the first dataprocessing means comprising any one or more of the same combinations.19. A method according to claim 18 wherein, in the case that the outputsignal comprises one or more combinations of data elements, togetherwith a condition indicator which is different from the conditionindicator of claim 18, the second data processing means generates anoutput signal which comprises a response selected from d) a signalterminating communications between the data processing means, and e) asignal consisting of any one or more of the same combinations.
 20. Amethod according to claim 16 wherein, in the event that the outputsignal comprises acceptance, the method further comprises the output ofa control signal to control a process or apparatus.
 21. A methodaccording to claim 16 wherein, in the event that the output signalcomprises a signal comprising at least one data element, said outputsignal is treated as an input signal by the second data processing meansand the second data processing means repeats the method of claim 15,outputting its output signal to the first data processing means, themethod being repeated in turn by the first and second data processingmeans until an output signal comprises either acceptance or rejection.22. A method according to claim 15 wherein the steps of reviewing theweighting factor allocated to each data element and generating an outputsignal determined by the reviewed weighting factors, comprise selectingfrom the stored data elements one or more data elements for which thecombined weighting factors are more favourable than the reviewedweighting factor(s) and the output signal comprises the selected set.23. A method according to claim 17 wherein each input and output signalwhich is transmitted between the data processing means, and comprises atleast one data element, comprises a set of data elements which togetherdefine a control signal.
 24. A method according to claim 20 and whereinthe control signal comprises a connection setup signal for acommunications network.
 25. A method according to claim 23 wherein theset of data signals which together define a control signal, define aconnection configuration for use in the connection setup.